【レポート】音声や動画像の低遅延AI処理を可能にする、機械学習モデル設計と実機向け最適化技術 #CEDEC2023 #classmethod_game
データアナリティクス事業本部 機械学習チームの鈴木です。
CEDEC2023に参加してきました。 聴講したセッション『音声や動画像の低遅延AI処理を可能にする、機械学習モデル設計と実機向け最適化技術』について学んだポイントと感想をまとめました。
この記事では私の感じたポイントと感想をざっくりとご紹介します。実際の発表資料に非常に詳しくポイントを記載頂いていたので、ご興味がある方はぜひCEDiLより発表資料をご確認頂ければと思います。
セッション概要
リアルタイムグラフィックスやオンラインマルチプレイなど、低遅延処理が随所で求められるゲームにおいて「前フレーム計算結果の再利用」と「差分への着目」は今なお根幹をなす最適化アプローチです。例えばちらつき軽減を目的としたTemporal Filter、物理シミュレーションにおける後退Euler 法、クライアントサーバー通信におけるデルタ圧縮はその一例と言えるでしょう。またCPU-GPU間のデータコピーに伴うボトルネック解消のため、ゲーム機はUMAやX Velocity Architectureといったハードウェアレベルの進化を遂げました。
こうした計算結果の再利用やゼロコピーといった文脈で、新たに機械学習モデルを書き起こしたり、カスタムオペレータをC++で組んだり、あるいは実機に特化した低レイヤチューニングを施して低遅延の限界を追求したAIの開発事例は、皆さんにとって初耳の内容ではないでしょうか？
本セッションはこうした取り組みの中で培った技術を共有すると共に、音声と動画像という２つのドメインにおいて既存ミドルウェアでは得られないであろうAIの成果を、目や耳でわかりやすく体感できる形でお伝えします。
※ 『音声や動画像の低遅延AI処理を可能にする、機械学習モデル設計と実機向け最適化技術』セッションページより引用
Vtuberアプリで必要とされるリアルタイムな推論、特に音声変換について、遅延に関する課題をデモを踏まえてご紹介頂き、またその課題をどのように技術的に解決したかについて事例や勘所を学ぶことができました。
ポイントと感じた点
デモによる音声変換の遅延の悪影響
最初に低遅延な音声変換が必要とされる理由をデモによって体験できました。
具体的には、音声変換に意図的な遅延を起こしてどのような違和感があるかを確認しました。
- 遅延50ms：ほぼ違和感なし
- 遅延100ms：ちょっと違和感があり遅く感じる
- 遅延200ms：一呼吸くらい遅く、明らかな違和感を感じる
今回は録音した音声とその変換結果のズレを体験しましたが、上記のように50ms程度に遅延を抑えないと違和感を感じました。
実際にアプリを使って自分が喋ったときの声と変換後の声がズレている場合、非常に使いづらいだろうなと感じ、低遅延を実現する必要性がよく理解できました。
理論的な推論の高速化のポイント
機械学習を使わないボイスチェンジャーの課題として、低い声を高い声に変換するといった、声色が大きく異なるサンプルについてうまく対応できないことがありました。
機械学習による手法では、発話内容と声色をうまく分離して変換することで、このような課題にも対応できるメリットがあることをご紹介頂きました。
一方で、機械学習を使う方法のデメリットとして、仕組み上、多くの行列演算が必要になるため計算量が大きくなってしまい、処理時間が大きくなりがちな点がありました。これは、デモで体験した通り、遅延によりUXを損ねる原因になります。
そのため、Causal Convolutionを使ったモデルを利用し、機械学習による音声変換手法の中でも高速な方法を検討して、ネットワークやI/Oによる影響も含めて50msの遅延に収める音声変換を実現できたことをご紹介頂きました。
デバイスへの実装
開発したモデルをどのようにiOS/Androidなどのデバイス上で実行させるかについても紹介頂きました。
デバイスでモデルを動かして推論を行う際、以下のようなデバイスならではの課題があることを学びました。
- 消費電力・発熱が重要になる。特に発熱があるとデバイス側の仕組みで処理実行が遅延させられる可能性がある。
- デバイスの仕様によってはGPU推論ができないことがある
同じモデルであっても組み込み方によって数倍、場合によっては数十倍の速度差が出るため、以下のようなポイントに気をつけることを知りました。
- 先人のレコードや論文での比較結果を参考にしつつ、アプリの性質と相性の良い推論ランタイムを選定する。
- 推論ランタイムの候補がいくつかある場合は、差し替えが容易になるようにラッパーを作成し、それを間に挟むような設計にする。
- ONNXへのコンバートなどでエラーが発生しても切り分けがしやすいように、ある程度の粒度に分割して開発をする。
- Pythonなどのパッケージ管理方法は統一する。（Poetryなど）
- 実機検証ではリソースのメトリックやトレースログを取得する。特にテンソル入出力など開発者があまり意識していないところがボトルネックになることがあるので気を付ける。
- リリース後もデバイス追加の対応などで実機検証することがあるので環境は残しておく。特にFirebase Test Labなどを使って検証環境をスケールできるようにしておく。
- 速度がでないときは、MACsや無駄な計算をしているオペレーターがないか調べる。
感想
デモを通して低遅延での推論が必要な理由がとてもよく理解できました。また、モデル組み込み時の推論ランタイムの選び方や開発・パフォーマンスチューニングの勘所についても多数のポイントが学べました。自分がモデルをデバイスに組み込むような場合には重要な観点として頭に入れておきたいと思います。
今回の音声変換とは異なるタスクですが、私の所属するチームでは軽量なモデルだとYOLOXなどを使った物体検出を検証をしていました。
上記ブログは今回紹介頂いたような環境より遥かに潤沢な計算機リソースで実行した場合になりますが、時間がかかってしまう場合や、デバイス上で実行するとき（YOLOXのGitHubレポジトリではONNXランタイムへのコンバートも紹介されていました）の解析には、今回学んだ内容がとても役立つだろうと思いました。
セッションを通してご紹介頂いた点を、ぜひ自業務に活かせればと思います。
